fix: handle non-numeric error codes from Microsoft Graph in OAuth callback#580
Merged
andris9 merged 1 commit intopostalsys:masterfrom Feb 26, 2026
Conversation
|
|
…lback Microsoft Graph API returns string error codes (e.g. "TooManyPendingRequests") in JSON error responses, unlike Google APIs which return numeric codes. Passing these strings to Boom.boomify() as statusCode causes an AssertError crash since Boom requires a numeric value >= 400. Extract resolveOAuthErrorStatus() helper into lib/tools.js to check if response.error.code is a valid numeric HTTP status code before using it, falling back to the HTTP status already captured on err.statusCode or err.oauthRequest.status.
bgeihsgt
force-pushed
the
fix/handle-non-numeric-graph-error-codes
branch
from
5a2f3ca to
898fc65
Compare
Collaborator
|
Thanks! Next time, you can just send the stack trace, no need to come up with an actual fix 🙂 |
andris9
approved these changes
Feb 26, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
When Microsoft Graph returns an error during OAuth profile fetch (e.g. HTTP 429 throttling), the JSON body contains a string
error.code(e.g."TooManyPendingRequests") rather than a numeric code. Passing this directly toBoom.boomify()asstatusCodecauses anAssertErrorcrash because Boom requires a numeric value >= 400.Gmail is unaffected because Google APIs return numeric
error.codevalues in their JSON error bodies (e.g.403,404). This bug manifests with Microsoft Graph (and potentially Mail.ru) because Microsoft uses string error codes like"TooManyPendingRequests","TooManyRequests","BadRequest", etc.Fix
All three instances of the pattern in
workers/api.js(Gmail, Outlook, and Mail.ru catch blocks) now check whetherresponse.error.codeis a valid numeric HTTP status code (number >= 400) before using it. If it's not numeric, the code falls back to the HTTP status code already captured on the error object (err.statusCodeorerr.oauthRequest.status), defaulting to 500 if neither is available.This preserves existing behavior for Google APIs while correctly handling string error codes from Microsoft Graph and other providers.
Steps to Reproduce
/oauthcallback handler crashes withAssertErrorinstead of returning a 429